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S easoned computer users recognize the names of 

the common hard disk drive interfaces: ESDI, 
ST506, and SCSI. Now there’s a new kid on the 
block—Intelligent Drive Electronics. 

The IDE interface, also known as the AT bus 
interface, turns up in more and more AT systems nowa¬ 
days. IDE combines features of the other three inter¬ 
faces and adds some extra benefits of its own. It’s al¬ 
ready a preferred interface and a de facto standard in 
the AT industry, and it’s on its way to becoming a full- 
fledged ANSI standard. IDE will likely be the demise 
of the ST506 interface, and it will banish ESDI and 
SCSI to use in only the highest-capacity applications in 
AT systems. 

The physical IDE interface is little more than an ex¬ 
tension of the AT I/O-channel expansion bus. The ac¬ 
tual hard disk drive controller is integrated onto the cir¬ 
cuit board of the hard disk drive. As a result, IDE is a 
very simple interface from a circuit standpoint: some 
bus buffers, address decoding, and little else. A single 
ribbon cable connects the drive to the host system, at¬ 
taching to mating header connectors on the host and 
drive. The interface circuitry is so simple and inexpen¬ 
sive that it can be easily integrated directly onto the 
motherboard of an AT system, freeing the expansion 
slot that’s required to accommodate a standard hard 
disk drive controller. (In case you’re wondering, most 
IDE implementations also provide floppy disk drive 
support on the motherboard.) 


A de facto standard 


The IDE drives are fast like A de TdCtO StdIN 
ESDI drives and intelligent ■ - - .. > - 

like scsi drives, and they interface threatens to 

look like standard AT ST506 _ _ ctbac pc m 

interfaces to the system. Most « ls P ,ace ST506, ESDI, 

IDE drives have 34 or more and SCSI for most 

sectors per track and run at a 

1 -to-1 interleave—the same as AT -Class systems 
typical ESDI drives. The 1- 
to-1 interleave results in very 

high performance. Most of these drives also have a 
32K- or 64K-byte memory buffer that allows sector 
caching, resulting in even faster effective operation. 

Making the IDE interface appear the same to the sys¬ 
tem as the ST506 controller that’s traditionally in¬ 
cluded with AT systems (including IBM’s original 6- 
MHz model) allows these computers to use IDE drives 
with the standard AT ROM BIOS; no BIOS modifica¬ 
tions or extensions are required. And even with its sev¬ 
eral advantages, the overall cost of an IDE hard disk 
subsystem is less than that of the alternatives. 

In short, the IDE interface is a great idea. Figure 1 
shows a traditional AT ST506 implementation; figure 2 
shows an IDE implementation. 

A Historical Perspective 

Compaq provided the initiative that led to the develop¬ 
ment of IDE. In late 1984, Compaq approached West¬ 
ern Digital, a leading manufacturer of hard disk drive 
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TRADITIONAL AT ST506 HARD DISK DRIVE IMPLEMENTATION 
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Figure 1: A traditional AT ST506 hard disk drive implementation. 
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controllers, about developing an ST506 
controller that could be mounted directly 
onto a hard disk drive, with a single 40- 
conductor ribbon cable connecting the 
controller to a simple interface circuit at 
the system. This project was the birth of 
the IDE interface. 

Compaq then approached Imprimis 
(which is now part of Seagate) in 1985 to 
integrate the controller electronics onto 
the circuit board of one of Imprimis’s 
Wren drives. Working under an aggres¬ 
sive development schedule, Imprimis 
succeeded in integrating the Western 
Digital circuitry onto the Wren drive 
controller board, creating the first IDE 
hard disk drive. Compaq became the 
first computer manufacturer to ship IDE 
drives in its systems. 

By integrating the controller circuitry 
onto the drive’s electronics board, an en¬ 
tire circuit board and some of the inter¬ 
face electronics could be eliminated. The 
result was little additional cost to the 
hard disk drive, but a substantial savings 
in the hard disk drive interface. 

Seeing the many benefits of the IDE 
interface over the standard interface al¬ 
ternatives, other drive manufacturers be¬ 


gan to implement the interface on their 
drives, and more AT system makers be¬ 
gan incorporating the drive interface into 
their designs. System manufacturers that 
did not yet include the IDE interface on 
their motherboards instead offered an 
adapter board, or “paddle board,” that 
plugged into an expansion slot to support 
the IDE interface. 

Over the past two years, the IDE inter¬ 
face has received phenomenal accep¬ 
tance while continuing to evolve. Al¬ 
though IDE first appeared on 5 % -inch 
Wren drives, it really came into its own 
on 3 1 / 2 -inch drives, where it has become 
the dominant interface. It’s also begin¬ 
ning to appear on the newer 2%-inch 
drives. 

As usage increased, the lack of an offi¬ 
cial IDE standard left substantial room 
for variations in the implementation of 
the interface among drive vendors and 
system implementors alike. This resulted 
in a variety of irritating incompatibilities 
that kept the interface from working con¬ 
sistently for all IDE system and drive 
designs. 

Increasingly aware of the variations in 
IDE implementations (as well as similar 


problems with SCSI implementations), a 
group of drive, system, and software 
manufacturers created a common-ac¬ 
cess-method committee to establish stan¬ 
dards in these areas. The CAM Commit¬ 
tee was formed in October 1988, and the 
first working document of the AT At¬ 
tachment (ATA) interface (the new name 
assigned to the IDE interface) was intro¬ 
duced in March 1989. 

After some revisions, an ATA draft 
proposal was finally submitted to the 
X3T9.2 ANSI working group in late 
1990, and it is scheduled for processing 
sometime during the first half of this 
year. The interface is now on the road 
to becoming an official standard. (The 
technical information presented in this 
article is based on revision 2.1 of the 
CAM Committee ATA draft proposal.) 

A Closer Look 

Like SCSI, IDE is a logic-level interface, 
not a device-level interface like ST506 
and ESDI. SCSI and IDE drives are intel¬ 
ligent; they accept high-level commands 
such as Format Track and Read Sector, 
and the electrical interface transfers 
commands and data between the system 
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IDE HARD DISK DRIVE IMPLEMENTATION 
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Figure 2: With IDE , the hard disk drive controller moves onto the hard disk , freeing an expansion slot. 
Simple, inexpensive circuitry on the motherboard is all that’s needed to accommodate an IDE drive. 


and the drive in 8- or 16-bit chunks. 

By contrast, an ST506 controller must 
control every low-level operation of the 
attached drive, including head selection 
and stepping to tracks. This means that 
intelligence has to reside on the ST506 
controller. Much of the magic of IDE 
comes from the intelligence of the 
drives. While looking at the technical 
specifics of IDE, keep in mind that the 
electrical interface itself is very simple, 
and all the significant functional elec¬ 
tronics are on the drive itself. 

The IDE interface consists of 40-pin 
header connectors on the system and on 
the drive, and a single interconnecting 
40-conductor ribbon cable. Pin 20 is re¬ 
moved from the header connectors and 
plugged into the cable connectors to pre¬ 
vent the cable from being incorrectly 
connected. Most of the IDE signals con¬ 
nect directly to AT I/O channel signals. 
Table 1 shows the IDE interface signals, 
along with signal directions and their re¬ 
spective AT I/O channel signal connec¬ 
tions. All the IDE signals are TTL-com- 
patible. Note that some signals are op¬ 
tional . 

The only IDE signals that do not di¬ 


rectly connect to AT I/O channel signals 
are CS1FX-, CS3FX-, SPSYNC, 
DASP —, and PDIAG — . The first two 
signals are the chip selects (address de¬ 
coding signals) for the drive command- 
block registers and control-block regis¬ 
ters. For compatibility with the IBM 
standard ST506 hard disk drive control¬ 
ler, the chip selects are active in the 1F0 
to 1F7 and 3F0 to 3F7 I/O-addressing 
ranges. The control registers for the AT 
floppy disk drive controller are also in 
the 3F0 to 3F7 range but are not present 
on the IDE drive. Table 2 lists the various 
hard disk drive registers defined at these 
addresses; for completeness, I have also 
listed the floppy disk drive controller 
registers. 

The IDE interface supports up to two 
drives on its 40-conductor cable in daisy- 
chain fashion. The primary drive, drive 
0, is referred to as the master , while the 
secondary drive, drive 1, is the slave. A 
jumper, or switch, on each drive is used 
to determine whether it is drive 0 or drive 
1. SPSYNC, DASP -, and PDIAG- are 
the drive intercommunication signals 
and are used in two-drive implementa¬ 
tions. The optional SPSYNC (for spindle 


sync) allows the master drive to generate 
a synchronous signal (e.g., from the 
drive’s index pulse) to the slave drive, al¬ 
lowing the slave to synchronize its rota¬ 
tion with the master. Disk mirroring 
would be one application for such syn¬ 
chronization; however, most existing 
IDE drives do not implement the SP¬ 
SYNC signal. Some earlier IDE drives 
used pin 28 for the DALE (drive address 
latch enable) signal instead of SPSYNC. 
However, DALE is not required, and it 
serves no useful purpose. 

DASP - (drive active/drive 1 present) 
is an open-collector signal that has dif¬ 
ferent functions at different times. Dur¬ 
ing power-on initialization or within 400 
milliseconds of the time RESET - is ne¬ 
gated (i. o., removed), drive 1 must assert 
this signal (i.e., pull it low) to inform the 
master of its presence. If the master does 
not see the signal asserted within 450 ms 
of when RESET— is negated, it assumes 
there is no slave drive. If the slave is pres¬ 
ent, it must then negate DASP— after it 
receives its first valid command from the 
system, or within 31 seconds (a good, 
round number), whichever comes first. 
After DASP- has been negated, or if no 
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slave is present, the DASP— signal can 
be used anytime by either drive as a 
drive-activity indicator. If that happens, 
it generally operates an LED indicator. 

Some prestandard IDE drives use this 
line strictly as an activity indicator and 
include on-drive jumpers to tell the drive 
that it is the only drive on the interface 


Notes: 

’The IDE Reset signal polarity is inverted from the AT bus signal. 
2 DASP- is also an interdrive signal. 


(or, for example, the master of a two- 
drive implementation). Since these 
drives do not follow the new standard, 
they will generally not work properly as 
drive 1 in a two-drive implementation if 
drive 0 conforms to the new standard. 
Since they do not look for the slave-pres¬ 
ent indication on the DASP— line, how¬ 


ever, they will usually work acceptably 
as drive 0 with a slave drive that con¬ 
forms to the new standard. 

PDI AG - (passed diagnostics) is a sig¬ 
nal used by drive 1 to tell drive 0 when 
(and if) it has passed its diagnostics fol¬ 
lowing a power-up or a reset. Drive 0 
uses this information to inform the sys¬ 
tem of a drive 1 failure. 

Most of the IDE interface signal func¬ 
tions are straightforward and obvious. 
RESET — (drive reset), as the name sug¬ 
gests, is from the reset signal generated 
by the system (although it is inverted 
from the actual reset signal on the AT I/O 
channel). DD0-DD15 (drive data bus), 
DA0-DA2 (drive address bus), DIOR- 
(drive I/O read), and DIOW — (drive I/O 
write) form the fundamental bus and 
strobe signals used to communicate back 
and forth between the system and the 
drive. INTRQ (drive interrupt) generates 
interrupt requests to the system (typical¬ 
ly for data, or sector, transfers), and it is 
usually connected to system interrupt 
IRQ14. IOCS 16— (drive 16-bit I/O) tells 
the system when 16-bit transfers are to 
take place; when it is unasserted, 8-bit 
transfers take place. 

The optional IORDY (I/O channel 
ready) signal is negated (i.e., dropped 
low) if the drive needs to extend the cur¬ 
rent host transfer cycle; otherwise it’s in 
a high-impedance state (a pull-up resis¬ 
tor resides on the system motherboard); 
most existing IDE drives do not use this 
signal. 

Two other optional IDE interface sig¬ 
nals are defined that should help future 
IDE drive implementations achieve even 
better performance: DMARQ (DMA re¬ 
quest) and DMACK— (DMA acknowl¬ 
edge). Current ST506 data transfer oper¬ 
ations (and, thus, virtually all existing 
IDE transfer operations) take place using 
programmed I/O (PIO); that is, the pro¬ 
cessor directly handles all data transfers 
between the controller and memory. The 
processor must, for example, read a word 
of data from memory, write it to the con¬ 
troller, and then repeat this process 255 
times to transfer a single sector to the 
controller. By supporting DMA, the pro¬ 
cessor can “rest” while the DMA con¬ 
troller transfers the data from the system 
memory to the controller (on the IDE 
drive) or vice versa, at up to twice the 
transfer rate of PIO. 

Before the introduction of the current 
IDE draft proposal, some IDE drive 
manufacturers, most notably Conner Pe¬ 
ripherals, chose pin 21 for IORDY in¬ 
stead of the now-standard pin 27. As a 
result, some existing drives put IORDY 
on both pins 21 and 27 (for backward and 


COMPARISON OF IDE AND AT I/O CHANNEL SIGNAL CONNECTIONS 


Table 1: With the exception of the chip selects and drive intercommunication 
signals , IDE signals connect directly to AT I/O channel signals (N/A = not 
applicable). 


IDE signal 
name 

IDE connector 
pin assignment 

AT I/O channel signal 
and pin assignment 

Signal 

direction 

Optional? 

RESET- 

1 

RESET DRV(inV) 

B2 

To drive 

No 

Ground 

2 

Ground 

N/A 

N/A 

No 

DD7 

3 

SD7 

A2 

Bidirectional 

No 

DD8 

4 

SD8 

C11 

Bidirectional 

No 

DD6 

5 

SD6 

A3 

Bidirectional 

No 

DD9 

6 

SD9 

C12 

Bidirectional 

No 

DD5 

7 

SD5 

A4 

Bidirectional 

No 

DD10 

8 

SD10 

C13 

Bidirectional 

No 

DD4 

9 

SD4 

A5 

Bidirectional 

No 

DD11 

10 

SD11 

C14 

Bidirectional 

No 

DD3 

11 

SD3 

A6 

Bidirectional 

No 

DD12 

12 

SD12 

C15 

Bidirectional 

No 

DD2 

13 

SD2 

A7 

Bidirectional 

No 

DD13 

14 

SD13 

C15 

Bidirectional 

No 

DD1 

15 

SD1 

A8 

Bidirectional 

No 

DD14 

16 

SD14 

C17 

Bidirectional 

No 

DDO 

17 

SD0 

A9 

Bidirectional 

No 

DD15 

18 

SD15 

C18 

Bidirectional 

No 

Ground 

19 

Ground 

N/A 

N/A 

No 

(key pin) 

20 

N/A 

N/A 

N/A 

No 

DMARQ 

21 

DRQx 

N/A 

From drive 

Yes 

Ground 

22 

Ground 

N/A 

N/A 

No 

DIOW - 

23 

-IOW 

B13 

To drive 

No 

Ground 

24 

Ground 

N/A 

N/A 

No 

DIOR - 

25 

- IOR 

B14 

To drive 

No 

Ground 

26 

Ground 

N/A 

N/A 

No 

IORDY 

27 

IOCHRDY 

A10 

From drive 

Yes 

SPSYNC 

28 

N/A 

N/A 

Interdrive 

No 

DMACK- 

29 

- DACKx 

N/A 

To drive 

Yes 

Ground 

30 

Ground 

N/A 

N/A 

No 

INTRQ 

31 

IRQ14 

D7 

From drive 

No 

IOCS16- 

32 

- I/OCS16 

D2 

From drive 

No 

DA1 

33 

SA1 

A30 

To drive 

No 

PDIAG - 

34 

N/A 

N/A 

Interdrive 

No 

DAO 

35 

SA0 

A31 

To drive 

No 

DA2 

36 

SA2 

A29 

To drive 

No 

CS1FX- 

37 

N/A 

N/A 

To drive 

No 

CS3FX - 

38 

N/A 

N/A 

To drive 

No 

DASP- 

39 

N/A 

N/A 

From drive 2 

No 

Ground 

40 

Ground 

N/A 

N/A 

No 
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current compatibility), since the drives 
do not support DMA operations and do 
not need the DMARQ signal on pin 21. 

The current IDE draft proposal speci¬ 
fies a maximum cable length of 18 inch¬ 
es, although it includes provisions for 
greater distances if signal integrity is 
controlled. Most IDE drive manufactur¬ 
ers specify a maximum cable length of 
24 inches. Fortunately, there is a reason¬ 
able amount of leeway in these specifica¬ 
tions. (I have seen IDE drives run suc¬ 
cessfully on 6-foot cables, although this 
is not recommended.) 

IDE’s cable length limitation is one of 
the few specifications that can be consid¬ 
ered a notable drawback when compared 
to the several feet of cable that are al¬ 
lowed in ST506 and SCSI implementa¬ 
tions. In reality, however, IDE drives 
rarely need to be more than 18 to 24 inch¬ 
es from the system interface connector, 
since the drives are mounted directly in¬ 
side the AT chassis. 

Being intelligent, IDE drives can ac¬ 
cept and respond to many commands 
from the host system. You issue a com¬ 
mand to the drive by initializing any ap¬ 
propriate support registers and then writ¬ 
ing a command byte to the drive ’ s com¬ 
mand register (at I/O address 1F7 hexa¬ 
decimal). The commands fall into two 
categories: mandatory and optional. The 
only mandatory commands are those 
supported by the original IBM AT ST506 
hard disk drive controller. 

The IDE commands (both the manda¬ 
tory and the optional ones) further subdi¬ 
vide into three operational classes, ac¬ 
cording to how the drive handles the 
request. Upon receiving a Class 1 com¬ 
mand, the drive sets the BSY (busy) bit 
in its status register within 400 nanosec¬ 
onds. Upon receiving a Class 2 com¬ 
mand, the drive sets the BSY bit, sets up 
its sector buffer for a write operation, 
sets the DRQ (data request) bit in its sta¬ 
tus register within 700 microseconds, 
and then clears its BSY bit. Upon receiv¬ 
ing a Class 3 command, the drive re¬ 
sponds the same as for a Class 2 com¬ 
mand, but it is allowed up to 20 ms to set 
its DRQ bit. Table 3 lists the IDE com¬ 
mands described in the current draft pro¬ 
posal. 

While it is impossible to discuss the 
operation of all the IDE commands in 
this limited space, the optional Read 
Multiple and Write Multiple com¬ 
mands deserve special note. Whereas the 
standard AT ST506 controller can only 
execute Read Sector and Write Sector 
commands, which require interrupt pro¬ 
cessing at the completion of each sector 
transfer, the IDE “multiple” commands 


permit multiple sectors to be transferred 
without intervening interrupts, yielding 
better data transfer performance. 

AT Support of IDE Drives 

Since the original intention was for IDE 
drives to work just like standard AT 
ST506 drives, most existing IDE drives 
support only the mandatory commands. 
As BIOS support for the optional com¬ 
mands becomes available, an increasing 
number of IDE drive vendors will cer¬ 
tainly be including support for these 
commands. 

The ROM BIOS in an AT system has a 
drive table that includes the drive param¬ 
eters for all hard disk drive types sup¬ 
ported by the BIOS. The parameters for 
each drive type in the table include num¬ 
ber of cylinders, number of read/write 
heads, number of sectors per track, and 
write-precompensation (if any). The ma¬ 
jority of the traditional AT ST506 drives 
employ MFM encoding, which corre¬ 
sponds to 17 sectors per track; therefore, 
most AT drive-table entries specify 17 
sectors per track. Most newer drives em¬ 
ploy RLL encoding, corresponding to 26 
sectors per track, so the drive table in 
most AT BIOSes now includes at least 
several entries for 26-sector-per-track 
drives. 

Existing AT BIOSes do not normally 
have drive-type entries with the 34 or 
more sectors per track common to most 
IDE drives. In the past, this sector den¬ 
sity has been traditionally reserved for 


SCSI and ESDI drives. Since one of the 
primary goals of IDE was to allow prop¬ 
er operation with existing AT BIOSes, 
these drives take advantage of their intel¬ 
ligence and make themselves look differ¬ 
ent than they really are. 

For example, the CP3044 drive from 
Conner Peripherals has 1047 cylinders, 
two heads, and 40 sectors per track. 
Even with a custom drive-table entry in 
an AT BIOS, this configuration could not 
be supported, since the BIOS can only 
handle a maximum of 1024 cylinders. 
The CP3044 drive, however, operates in 
a translate mode that makes the drive ap¬ 
pear to have 980 cylinders, five heads, 
and 17 sectors per track. Note that the 
number of sectors is nearly the same 
(1047 x 2 x 40 = 83,760 sectors, com¬ 
pared to 980 x 5 x 17 = 83,300 sec¬ 
tors), so the total drive capacity is effec¬ 
tively unchanged. 

Most drives have an equal number of 
sectors on every track. However, since 
the platters rotate at a constant speed, 
data is stored more densely on the tracks 
closest to the spindle. That makes the 
data density of the innermost track the 
limiting factor in storing data on the plat¬ 
ters. For greater capacity, some IDE 
drives take advantage of zone recording , 
in which an attempt is made to keep the 
linear density of the stored data fairly 
constant so the tracks (or cylinders) are 
divided into zones. 

For example, the Quantum ProDrive 
LPS 52AT drive has three recording 


_ HARD DISK DRIVE REGISTER DEFINITIONS _ 

Table 2: For compatibility with the standard ST506 controller, chip selects 
are active in the lF0-to-lF7 and 3F0-to-3F71/O-addressing ranges (N/A = 
not applicable). 


I/O address 

Read 

register 

Write 

register 

Hard or floppy? 

1F0 

Data register 

Data register 

Hard 

1 FI 

Error register 

Write precomp 

Hard 

1F2 

Sector count 

Sector count 

Hard 

1F3 

Sector number 

Sector number 

Hard 

1F4 

Cylinder low 

Cylinder low 

Hard 

1F5 

Cylinder high 

Cylinder high 

Hard 

1F6 

Drive/head 

Drive/head 

Hard 

1F7 

Status register 

Command register 

Hard 

3F2 

N/A 

Digital output 

Floppy 

3F4 

Main status 

Main status 

Floppy 

3F5 

Diskette data 

Diskette data 

Floppy 

3F6 

N/A 

Fixed disk 

Hard 

3F7 

Digital input 

Diskette control 

Hard/floppy* 


Notes: 

* The digital-input register includes 7 bits for the hard disk and one for the floppy disk. 
All I/O addresses are in hexadecimal. 
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zones. Zone 0 has 49 sectors per track, 
zone 1 has 42, and zone 2 has 35. Such a 
configuration would be impossible to 
specify in a standard AT BIOS drive 
table, but an IDE drive can operate in its 
translate mode and appear to the system 
as a standard AT drive with 17 sectors 
per track on all cylinders. The transla¬ 
tion for the Quantum drive is 751 cylin¬ 


ders, eight heads, and 17 sectors per 
track. 

IDE drives vary in how they handle the 
logical-to-physical sector translation. 
Most support only fixed translation, in 
which the drive’s logical (AT) configura¬ 
tion must be used only as specified. 
Other drives offer variable translation, 
where any entry in the AT BIOS’s drive 


table can be used as long as the total num¬ 
ber of sectors in the chosen drive type 
does not exceed the total number of phys¬ 
ical sectors on the IDE drive. Because 
any precompensation that may be needed 
is handled internally, IDE drives ignore 
the precompensation value in the AT 
BIOS drive table. 

Other IDE Advantages 

In addition to the many advantages that I 
have already described, IDE drives shine 
in other areas as well. A large number 
of IDE drives include a special feature 
called automatic bad-sector remapping , 
which helps ensure long-term reliability. 
These drives have spare sectors that are 
reserved for future use. When the drive 
detects a sector-read error several times 
in succession, the data is recovered (us¬ 
ing the Reed-Solomon error-correction 
code that is stored with the sector) and 
stored in one of the spare sectors. The 
bad sector is then tagged as unusable, 
and the new sector is put into the drive’s 
lookup table as the replacement for the 
bad sector. 

IDE drives generally have power-con¬ 
sumption advantages over other drives. 
A large majority of IDE drives are of the 
3^2-inch form factor and are often used 
in applications where minimal power 
consumption is desirable. As the trend 
continues toward increased usage of 2 Vi - 
inch drives and low-profile (1-inch-high) 
3 1 /2-inch drives, even more emphasis is 
being placed on using very-low-power 
components on these drives. The current 
draft proposal includes commands to 
place the drive in one of four power con¬ 
ditions: Active, Idle, Standby, and Sleep, 
in order of diminishing power consump¬ 
tion. When implemented, this will be es¬ 
pecially important for battery-operated 
laptop computers. 

The Dark Side of the Force 

While my description of IDE up to this 
point has been glowing—and justifiably 
so—there are, inevitably, some draw¬ 
backs. The most obvious one is the lack 
of standardization. With the introduction 
of the draft proposal and the current 
standardization efforts, however, the in¬ 
compatibilities that have surfaced in 
varying implementations should gradual¬ 
ly disappear. 

As anyone who has been around the 
PC industry for a while can attest, 100 
percent compatibility is a very difficult 
and elusive goal. This is no less true with 
IDE. While every attempt has been made 
to make IDE drives look like standard 
AT ST506 drives to an AT, the imple¬ 
mentation of this facade has not always 


_ IDE COMMANDS _ 

Table 3: Mandatory commands are those supported by the original IBM AT 
ST506 controller. When BIOS support for optional commands, such as Read 
Multiple and Write Multiple, materializes, drive vendors will be able to 
support IDE’s advanced capabilities. All command codes are in hexadecimal; 
N/A = not applicable. 


Command 

Class 

Command 

code 

Optional? 

Check Power Mode 

1 

98 E5 

Yes 

Execute Drive Diagnostic 

1 

90 

No 

Format Track 

2 

50 

No 

Identify Drive 

1 

EC 

Yes 

Idle 

1 

97 E3 

Yes 

Idle Immediate 

1 

95 El 

Yes 

Initialize Drive Parameters 

1 

91 

No 

Recalibrate 

1 

lx 

No 

Read Buffer 

1 

E4 

Yes 

Read DMA (with retry) 

1 

C8 

Yes 

Read DMA (without retry) 

1 

C9 

Yes 

Read Multiple 

1 

C4 

Yes 

Read Sector(s) (with retry) 

1 

20 

No 

Read Sector(s) (without retry) 

1 

21 

No 

Read Long (with retry) 

1 

22 

No 

Read Long (without retry) 

1 

23 

No 

Read Verify Sector(s) (with retry) 

1 

40 

No 

Read Verify Sector(s) (without retry) 

1 

41 

No 

Seek 

1 

7x 

No 

Set Features 

1 

EF 

Yes 

Set Multiple Mode 

1 

C6 

Yes 

Set Sleep Mode 

1 

99 E6 

Yes 

Standby 

1 

96 E2 

Yes 

Standby Immediate 

1 

94 E0 

Yes 

Write Buffer 

2 

E8 

Yes 

Write DMA (with retry) 

3 

CA 

Yes 

Write DMA (without retry) 

3 

CB 

Yes 

Write Multiple 

3 

C5 

Yes 

Write Same 

3 

E9 

Yes 

Write Sector(s) (with retry) 

2 

30 

No 

Write Sector(s) (without retry) 

2 

31 

No 

Write Sector(s) (with retry) 

2 

32 

No 

Write Sector(s) (without retry) 

2 

33 

No 

Write Verify 

3 

3C 

Yes 

Vendor unique 

N/A 

9A 

N/A 

Vendor unique 

N/A 

C0-C3 

N/A 

Vendor unique 

N/A 

8x 

N/A 

Vendor unique 

Reserved: all remaining codes 

N/A 

F5-FF 

N/A 
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been perfect, even though the registers 
look the same and the commands work 
identically. Subtleties sometimes creep 
in and spoil everything. 

In one case, for example, a company’s 
employees were happily using a 100- 
megabyte IDE hard disk drive on their 
386-based DOS system. They subse¬ 
quently installed an IBM Token Ring 
network, a Qualitas 386Max driver, and 
a custom application program. This con¬ 
figuration had run successfully in the 


past with a standard ST506 drive, but oc¬ 
casional data-read errors started occur¬ 
ring when running with the IDE drive. 
Replacing the drive with another of the 
same type did not fix the problem. 

It turned out that 386Max and the IDE 
drive did not get along very well. When 
386Max switched into protected mode, 
the drive could not respond fast enough 
to commands. Ironically, an earlier re¬ 
lease of 386Max worked fine, as did the 
similar QEMM-386 driver from Quar¬ 


terdeck. An IDE drive from a different 
manufacturer worked successfully in the 
application and solved the problem; its 
internal timing was just different enough 
to matter. These kinds of anomalies will 
likely go away as the IDE drive market 
matures. 

IDE drives also differ from standard 
ST506 drives when it comes to tradition¬ 
al hard disk utilities. For example, IDE 
drives are low-level-formatted at the fac¬ 
tory, and you cannot employ any low- 
level-format utility to reformat the drive. 
Remember, the IDE drive has only a log¬ 
ical appearance to the AT, so a standard 
low-level-format utility could not work 
correctly. 

Similarly, other utilities that attempt 
to modify the drive’s sector interleave to 
determine the best performance point 
will not work. Virtually all IDE drives 
are configured for a 1 -to-1 interleave in¬ 
ternally, and they don’t support inter¬ 
leave changes. Even drive-performance 
benchmark utilities will not be complete¬ 
ly accurate. For example, when measur¬ 
ing seek time or head-select time, only 
the logical heads are “moving,” and the 
actual physical movement of the drive’s 
heads will be much less (perhaps one- 
fourth as much). 

IDE is rapidly becoming the dominant 
hard disk drive interface in the AT mar¬ 
ketplace, and for some very good rea¬ 
sons. It offers manufacturers and users a 
“win-win” drive alternative. IDE drives 
are less expensive than their controller/ 
drive combo counterparts, yet they offer 
more flexibility, better functionality, AT 
compatibility, faster speed, and easier 
implementation. Better yet, the ATA in¬ 
terface specification is now well on its 
way to official ANSI standardization. 
IDE drives are now available with capac¬ 
ities of up to 300 MB, and even larger 
disks loom on the horizon. Odds are that 
there’s an IDE hard disk drive in your 
future. ■ 
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